The present invention generally relates to accessing World Wide Web using Web browsers, and more particularly to a new user security profile feature for Web browsers.
Today, people use Web browsers such as Netscape browsers and Internet Explorer to communicate with Web servers which serve Web pages to browsers by the HyperText Transfer Protocol (HTTP). The HTTP protocol is a client-server protocol where HTTP clients (also known as browsers) send the Web server the identifier of the Web page (commonly known as URL or Uniform Resource Locator) that the user wants to retrieve. Upon receiving the URL sent by the browsers, a Web server sends the requested page to the requesting browsers and the browsers present the received page to the users via a graphical user interface (GUI). A Web page typically contains hyperlinks that point to other Web pages; users can request these pages by clicking on the hyperlink. A user can save the URL of the Web page he is visiting in a bookmark file so that he can revisit the page next time by just clicking on the corresponding bookmark entry. A user can also retrieve a Web page by typing the URL as a text string into the browser.
In addition to the aforementioned browsers with a graphical user interface (GUI), there exists other types of browsers which do not have GUI. An example is voice browsers which can be used by people with impaired vision or people whose eyes are not available while navigating the Web, e.g., automotive drivers. With the lack of a GUI interface, a voice browser typically employs text-to-speech technology to covert the text information of Web pages into speech signals and speech recognition technology to recognize what the user said. With the maturity today""s speech technology, a user typically say the number or the keywords that are associated with the page he wants to get. With such a restricted user interface, it is very difficult for users to specify a URL by spelling out the URL letter by letter or word by word.
Another example of browsers without GUI interface is a phone browser system. FIG. 1 shows a system diagram of a typical phone browser system. The phone browser system allows a telephone user to access the Web pages (not shown) residing at Web servers 170 on the Internet. The system works as follows. A caller picks up a phone 105 and dials the phone number corresponding to the URL of the Web page that he/she wants to reach. The phone call will be routed by the PSTN (public switch telephone network) 110 to a IVR platform 120 which on one hand interfaces with the PSTN I 10 and on the other hand interfaces with the Internet 150, to which a phone browser 160 and a Web server 170 are connected. The phone call will be picked up at the IVR platform 120 by the call handling routine 122 which will find the destined URL by looking up the phone number/URL table 124 based on the phone number the caller dialed. The call handling routine 122 then proceeds to establish a session with a phone browser 160 and initializes the phone browser 160 with the selected URL by a proprietary protocol, called V protocol. The phone browser 160 then interacts with the Web server 170 hosting the destined URL by the HTTP protocol.
The IVR platform 120 interfaces with the PSTN via a telephony interface 128 which includes DTMF (Dual-Tone Multi-Frequency) detection, call answering/disconnecting, digital-to-analog and analog-to-digital converters, etc. The IVR platform 120 includes audio functions 126 such as text-to-speech converters, audio players, audio recorders, etc. The information (e.g. text and audio) obtained from the Web server 170 is first processed by the phone browser 160 (e.g., appending a voice menu at the end of the page.) The processed information is then sent to the call handling routine 122 via V protocol. The received information at the call handling routine 122 is presented to the caller after the necessary conversion is done at the IVR platform 120. The caller now listens to the transformed Web page in speech and chooses the next URL by pressing the corresponding touch-tone button on the phone 105 according to the voice menu presented to the caller by the call handing routine 122. The call handling routine 122 converts the received DTMF tone into a digital format (e.g., ASCII text) and sends it to the phone browser for the next Web page. The process repeats till the caller hangs up the phone. Similar to the situation in a voice browser system, it is very difficult for a user to supply a URL in text in a phone browser system.
With the growing awareness of security and privacy, today many Web sites require users sign up and set up a login username and password when users first visit their Web sites. When a user tries to download a page that is password protected, the browser will prompt the user to supply username and password as a result of receiving a password challenge from the Web server hosting the page. As such, each user has to manage a list of login information (i.e., URL, username, and password) for each site he signs up and manually supply the username and password every time he visits these sites.
For a browser with GUI, it is extra work to manage the many usernames and passwords for all the sites that are password protected. Some users may find it inconvenient to supply username and password each time a password-protected site is visited. For browsers without GUI such as voice browsers and phone browsers, it is very difficult to for users to tell the browsers username and password.
An object of this invention is a method for users to access password-protected Web sites without manually supplying username and password for each visit of the sites.
Another object of the invention is a method for telephone users to access password-protected web sites without supplying username and password information over the phones.
The present invention is a system and method for accessing password-protected Web sites through Web browsers without manually supplying a username and password by the users. The invention requires a browser maintains, for each user, one user security profile which stores the URLs and the corresponding login username and password. When the browser receives a username-password challenge from a Web server, instead of immediately prompting the user for such information, the browser first searches the user security profile for the URL the challenge is received from. If a match is found, the browser sends the challenging Web server the username and password that is associated with the matched URL. Thus the user does not have to manually supply the username and password once the triple of (URL, username, password) is stored in the user security profile. This feature is especially valuable for users of voice browsers and phone browsers.